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(57) ABSTRACT 

A flexible gateway accommodates data transfer from a data 
origination device over a wide variety of networks to a wide 
variety of destination devices, even if those networks use 
different protocols, and even if the devices recognize dif- 
ferent data formats. Thus, the gateway can perform work 
previously requiring numerous gateways. After the gateway 
receives information from a data source, the gateway iden- 
tifies the specific device type and the specific network type 
to which the information is to be routed. The gateway then 
calls device and network drivers associated with the specific 
device and network identified with the destination device. 
These drivers then manipulate the data using the device 
driver into the format recognized by the destination device, 
and then provide the manipulated data to the destination 
device over the identified network using the compatible 
protocol. Thus, the destination device properly receives and 
interprets the information provided by the data source. If, in 
the very next moment, data arrives at the gateway that is to 
be routed over a different network using a different protocol 
to a different device recognizing a different device, the 
gateway will call different device and network drivers to 
enable the communication. 

32 Claims, 5 Drawing Sheets 
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FLEXIBLE SYSTEM AND METHOD FOR 
COMMUNICATING BETWEEN A BROAD 
RANGE OF NETWORKS AND DEVICES 

BACKGROUND OF THE INVENTION 

1. The Field of the Invention 

The present invention relates to data processing systems. 
Specifically, the present invention relates to a gateway for 
flexibly interfacing a broad range of data origination devices 
with a broad range of data destination devices over a broad 
range of networks. 

2. The Prior State of the Art 

Human beings communicate with each other using a set of 
rules called a protocol. For example, in one culture, it might 
be proper to initiate a conversation with a business contact 
by shaking hands. During the conversation, it might be 
proper to listen and abstain from speaking while the contact 
is speaking, and to make eye contact. To end the 
conversation, it might be proper to state a closing remark 
such as "good bye" or "I'll see you later." A protocol also 
governs the way that computers communicate or exchange 
data within a given network. For example, a standard 
Internet protocol is termed HyperText Transport Protocol or 
HTTP. 

Returning to the business contact analogy, from culture to 
culture, there may be a different protocol for initiating a 
conversation with a business contact. For example, in one 
culture, a hand shake will suffice. In another, a slight bow, 
a simultaneous hand shake, and a subsequent business card 
exchange might be appropriate. In yet another, a kiss on the 
cheek might be appropriate. What is proper in one culture 
may be completely inappropriate and unthinkable in another. 
Computer networks may also vary in protocol from network 
to network. Yet, it is important, especially with the advent 
and proliferation of the Internet, that devices from different 
networks communicate with each other even if they use 
different protocols. 

A gateway is a device that acts as a go-between between 
different networks. A data origination device will commu- 
nicate information over a network to the gateway using the 
protocol appropriate for that network. The gateway will then 
relay that information over another network to the destina- 
tion device using a protocol appropriate for the second 
network. Sometimes the protocols for the first and second 
networks are the same; but often, they are different. Thus, 
the gateway permits communication of data over multiple 
networks even if those networks have different protocols. 

Gateways are not functionally limited to just translating 
protocols, but may also perform a variety of other functions 
such as converting the message data from the format gen- 
erated by the origination device into a format recognizable 
by the destination device. For example, the gateway may 
convert a graphics file from Graphics Interchange Format. 
(GIF) to Bitmap (BMP) format. 

Gateways have greatly facilitated inter- network commu- 
nication. However, conventional gateways are highly inflex- 
ible as they can only deal with specific protocols. For 
example, a gateway that receives data using the HTTP 
protocol, and transmits that data using another specific 
protocol such as Kermit File Transfer Protocol (Kermit FTP) 
can only receive data using HTTP, and can only transmit 
using Kermit FTP. The gateway would not transmit using 
HTTP or any other protocol except Kermit FTP. 

Another inflexibility in conventional gateways is that the 
gateway only converts data formats from one specific format 
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to another specific format. For example, a gateway that 
converts data from the Rich Text Format (RTF) into the 
American Standard Code for Information Interchange 
(ASCII) format only converts from RTF format into ASCII 
5 format. 

Due to this inflexibility, device manufacturers are 
impeded from introducing new devices that recognize a 
proprietary data format type. Specifically, the device manu- 
facturer might have to construct numerous gateways to 

10 enable data to be translated into the new format recognizable 
by the new device. The number of gateways needed for a 
particular device is a function of the number of data formats 
provided to the gateway, the number of protocols used to 
communicate the data to the gateway, and the number of 

15 protocols used to communicate the data from the gateway to 
the particular device. 

Furthermore, a new carrier provider having its own pro- 
tocol might also have to provide a number of gateways. This 
number is a function of the number of data formats and 

20 protocols with which data is communicated to the gateway, 
and the number of data formats recognizable by each device 
with which the carrier communicates. 

In the wireless world, there is a host of wireless devices 
available, many of which only recognize their own propri- 

25 etary data format. Furthermore, there are many wireless 
carriers available, each using its own protocol. Therefore, 
the number of conventional gateways needed to accommo- 
date every wireless carrier and every wireless device is 
immense. Thus, the burden to provide gateways is great. 

It is desirable to reduce the number of gateways needed to 
exchange data with a wide range of networks and devices 
such as in the wireless world. 

SUMMARY OF THE INVENTION 

In accordance with the present invention, a flexible gate- 
way is provided. The gateway accommodates data transfer 
from a data origination device over a wide variety of 
networks to a wide variety of destination devices, even if 

40 those networks use different protocols, and even if the 
devices recognize different data formats. Thus, the gateway 
can perform work previously requiring numerous gateways. 
The gateway is particularly useful in communicating over 
wireless networks to wireless devices since these networks 

4 5 and devices in aggregate have numerous proprietary proto- 
cols and data formats. However, the advantage of the 
gateway can be incorporated into wired networks as well, as 
will be recognized to one skilled in the field of computer 
networks from having read this disclosure. 

50 After the gateway receives information from a data 
source, the gateway identifies the specific device type of the 
destination device, and the specific network type of the 
destination network on which the destination device resides. 
For example, if the information is intended to go to John 

55 Doe's cellular phone, the gateway would determine the 
specific type of cellular phone that John Doe is using (e.g., 
ABC ALPHATEXT PHONE 50000), and the specific net- 
work that is connected to the phone (e.g., WIRELESS 
NETWORK XYZ). Alternatively, the specific device type 

60 and network type may be included with the information 
provided to the gateway. 

The gateway calls the appropriate device and network 
drivers associated with the specific device and network to 
create a chain of driver modules customized to the destina- 

65 tion device and destination network. This driver chain then 
manipulates the data into the format recognized by the 
destination device, and then provides the manipulated data 
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to the destination device over the destination network using 
the compatible protocol. Thus, the target device properly 
receives and interprets the information provided by the data 
source. 

If, in the very next moment, data arrives at the gateway 
that is to be routed over a different network using a different 
protocol to a different device recognizing a different format, 
the gateway would call different device and network drivers 
to customize a chain of drivers for that particular destination 
device and network. 

One important benefit is that this gateway may commu- 
nicate data to a wide variety of devices over a wide variety 
of networks. The number of devices and networks with 
which the gateway can work is limited only by the number 
of device and network drivers available to the gateway. This 
flexibility is particularly beneficial in the wireless world 
where formats and protocols tend to vary device-to-device 
and network-to-network. The gateway is also flexible in that 
it may facilitate both unidirectional and bi-directional com- 
munication. Information may be communicated from the 
data origination device to the destination device as described 
above. However, depending on the capability of the desti- 
nation device, the destination device may also communicate 
information to the origination device. That information 
might be, for example, a request for the information that the 
origination device is to send to the destination device. 

The gateway may also call customized drivers other than 
the device and network drivers. For example, if the desti- 
nation device is loaded with certain encryption software for 
decoding a certain type of encryption, the gateway may first, 
identify whether encryption is desired for a given message 
based on the device capabilities, then identify the appropri- 
ate encryption driver for the certain type of encryption, and 
then call the appropriate encryption module. 

Additional objects and advantages of the invention will be 
set forth in the description which follows, and in part will be 
obvious from the description, or may be learned by the 
practice of the invention. The objects and advantages of the 
invention may be realized and obtained by means of the 
instruments and combinations particularly pointed out in the 
appended claims. These and other objects and features of the 
present invention will become more fully apparent from the 
following description and appended claims, or may be 
learned by the practice of the invention as set forth herein- 
after. 

BRIEF DESCRIPTION OF THE DRAWINGS 

In order that the manner in which the above-recited and 
other advantages and objects of the invention are obtained, 
a more particular description of the invention briefly 
described above will be rendered by reference to specific 
embodiments thereof which are illustrated in the appended 
drawings. Understanding that these drawings depict only 
typical embodiments of the invention and are not therefore 
to be considered limiting of its scope, the invention will be 
described and explained with additional specificity and 
detail through the use of the accompanying drawings in 
which: 

FIG. 1 illustrates an exemplary system that provides a 
suitable operating environment for the present invention; 

FIG. 2 is a schematic diagram showing the passage of a 
message through a gateway in accordance with the present 
invention; 

FIG. 3 is a schematic diagram demonstrating the scal- 
ability of the gateway shown in FIG. 1 in accordance with 
the present invention; 
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FIG. 4 is a schematic diagram of the gateway of FIG. 2 
and FIG. 3 having a locator module and capable of calling 
through standardized interfaces from libraries of device 
modules, network driver modules, and encryption modules; 

FIG. 5 is a diagram of a table represented by a data 
structure residing in the mass memory of FIG. 4, the table 
associating a generic address with a specific address of the 
destination device of FIG. 2 and FIG. 3; and 

FIG. 6 is a diagram of a table represented by a data 
structure residing on the mass memory of FIG. 4, the table 
associating the specific address of the destination device 
with a specific device type of the destination device and a 
specific network type of the network upon which the desti- 
nation device resides. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A flexible gateway accommodates data transfer from a 
data origination device over a wide variety of networks to a 
wide variety of destination devices, even if those networks 
use different protocols, and even if the devices recognize 
different data formats. Thus, the gateway can perform work 
previously requiring numerous gateways. The gateway is 
particularly useful in communicating over wireless networks 
to wireless devices since these networks and devices in 
aggregate have numerous proprietary protocols and data 
formats. However, the advantage of the gateway can be 
incorporated into wired networks as well, as will be recog- 
nized to one skilled in the field of computer networks from 
having read this disclosure. 

The invention is described below by using diagrams to 
illustrate either the structure or processing of embodiments 
used to implement the systems and methods of the present 
invention. Using the diagrams in this manner to present the 
invention should not be construed as limiting of its scope. 
The present invention contemplates both methods and sys- 
tems for forwarding messages from an origination device to 
a destination device. The embodiments of the present inven- 
tion may comprise a special purpose or general purpose 
computer including various computer hardware, as dis- 
cussed in greater detail below. 

Embodiments within the scope of the present invention 
also include computer-readable media for carrying or having 
computer-executable instructions or data structures stored 
thereon. Such computer-readable media can be any available 
media which can be accessed by a general purpose or special 
purpose computer. By way of example, and not limitation, 
such computer- readable media can comprise RAM, ROM, 
EEPROM, CD-ROM or other optical disk storage, magnetic 
disk storage or other magnetic storage devices, or any other 
medium which can be used to carry or store desired program 
code means in the form of computer-executable instructions 
or data structures and which can be accessed by a general 
purpose or special purpose computer. Such a medium may 
include a wireless carrier signal, for example. When infor- 
mation is transferred or provided over a network or another 
communications connection (either hardwired or wireless) 
to a computer, the computer properly views the connection 
as a computer-readable medium. Thus, any such connection 
is properly termed a computer-readable medium. Combina- 
tions of the above should also be included within the scope 
of computer- readable media. Computer-executable instruc- 
tions comprise, for example, instructions and data which 
cause a general purpose computer, special purpose 
computer, or special purpose processing device to perform a 
certain function or group of functions. 
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FIG. 1 and the following discussion are intended to 
provide a brief, general description of a suitable computing 
environment in which the invention may be implemented. 
Although not required, the invention will be described in the 
general context of computer-executable instructions, such as 5 
program modules, being executed by computers in network 
environments. Generally, program modules include 
routines, programs, objects, components, data structures, 
etc. that perform particular tasks or implement particular 
abstract data types. Computer-executable instructions, asso- 
ciated data structures, and program modules represent 
examples of the program code means for executing steps of 
the methods disclosed herein. The particular sequence of 
such executable instructions or associated data structures 
represent examples of corresponding acts for implementing 1$ 
the functions described in such steps. 

Those skilled in the art will appreciate that the invention 
may be practiced in network computing environments with 
many types of computer system configurations, including 
personal computers, hand-held devices, multi-processor 20 
systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe 
computers, and the like. The invention may also be practiced 
in distributed computing environments where tasks are 
performed by local and remote processing devices that are 25 
linked (either by hardwired or wireless links) through a 
communications network. In a distributed computing 
environment, program modules may be located in both local 
and remote memory storage devices. 

FIG. 1 illustrates a conventional computer 20 that 30 
includes components and data processing capabilities that 
may be used to implement embodiments of the invention. 
Computer 20 is a general purpose computing device that 
includes a processing unit 21, a system memory 22, and a 
system bus 23 that couples various system components 35 
including the system memory 22 to the processing unit 21. 
The system bus 23 may be any of several types of bus 
structures including a memory bus or memory controller, a 
peripheral bus, and a local bus using any of a variety of bus 
architectures. The system memory includes read only 40 
memory (ROM) 24 and random access memory (RAM) 25. 
A basic input/output system (BIOS) 26, containing the basic 
routines that help transfer information between elements 
within the computer 20, such as during start-up, may be 
stored in ROM 24. 45 

The computer 20 may also include a magnetic hard disk 
drive 27 for reading from and writing to a magnetic hard 
disk 39, a magnetic disk drive 28 for reading from or writing 
to a removable magnetic disk 29, and an optical disk drive 
30 for reading from or writing to removable optical disk 31 50 
such as a CD-ROM or other optical media. The magnetic 
hard disk drive 27, magnetic disk drive 28, and optical disk 
drive 30 are connected to the system bus 23 by a hard disk 
drive interface 32, a magnetic disk drive-interface 33, and an 
optical drive interface 34, respectively. The drives and their 55 
associated computer-readable media provide nonvolatile 
storage of computer-executable instructions, data structures, 
program modules and other data for the computer 20. 
Although the exemplary environment described herein 
employs a magnetic hard disk 39, a removable magnetic disk 60 
29 and a removable optical disk 31, other types of computer 
readable media for storing data can be used, including 
magnetic cassettes, flash memory cards, digital video disks, 
Bernoulli cartridges, RAMs, ROMs, and the like. 

Program code means comprising one or more program 65 
modules may be stored on the hard disk 39, magnetic disk 
29, optical disk 31, ROM 24 or RAM 25, including an 
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operating system 35, one or more application programs 36, 
other program modules 37, and program data 38. A user may 
enter commands and information into the computer 20 
through keyboard 40, pointing device 42, or other input 
devices (not shown), such as a microphone, joystick, game 
pad, satellite dish, scanner, or the like. These and other input 
devices are often connected to the processing unit 21 
through a serial port interface 46 coupled to system bus 23. 
Alternatively, the input devices may be connected by other 
interfaces, such as a parallel port, a game port or a universal 
serial bus (USB). A monitor 47 or another display device is 
also connected to system bus 23 via an interface, such as 
video adapter 48. In addition to the monitor, personal 
computers typically include other peripheral output devices 
(not shown), such as speakers and printers. 

The computer 20 may operate in a networked environ- 
ment using logical connections to one or more remote 
computers, such as remote computers 49a and 496, Remote 
computers 49a and 49b may each be another personal 
computer, a server, a router, a network PC, a peer device or 
other common network node, and typically includes many or 
all of the elements described above relative to the computer 
20, although only memory storage devices 50a and 506 an 
their association application programs 36a and 36b have 
been illustrated in FIG. 1. The logical connections depicted 
in FIG. 1 include a local area network (LAN) 51 and a wide 
area network (WAN) 52 that are presented here by way of 
example and not limitation. Such networking environments 
are commonplace in office -wide or enterprise -wide com- 
puter networks, intranets and the Internet. 

When used in a LAN networking environment, the com- 
puter 20 is connected to the local network 51 through a 
network interface or adapter 53. When used in a WAN 
networking environment, the computer 20 may include, for 
example, a modem 54 or a wireless link. The modem 54, 
which may be internal or external, is connected to the system 
bus 23 via the serial port interface 46. In a networked 
environment, program modules depicted relative to the 
computer 20, or portions thereof, may be stored in the 
remote memory storage device. It will be appreciated that 
the network connections shown are exemplary and other 
means for establishing communications over wide area 
network 52 may be used. 

FIG. 2 shows a schematic diagram of an environment 200 
for a gateway 240 according to the present invention. The 
gateway 240 may comprise, for example, a computer like 
the computer 20 of FIG. 1 and interacts with networks 220, 
260, and 261 external to the computer 20 as shown in FIG. 
2. Alternatively, gateway 240 may be implemented in any 
other suitable processing device or system that performs the 
functions disclosed herein. The gateway 240 of the present 
invention is flexible, accommodating many types of data 
format conversions and many types of protocol conversions. 

In the environment 200 of FIG. 2, an originating device 
210 forwards a message 280 through an originating network 
220, through a sending queue 230, and to the gateway 240. 
The message 280 can include any data whether it be text, 
graphics, executables, or otherwise. The gateway 240 pro- 
cesses the message 280 and forwards the message 280 
through a remote queue 250, through a remote network 260, 
and to the remote device 270. Remote network 261 and 
remote device 271 will also be described below. In this 
description, "originating" corresponds to either the left or 
right side of the gateway 240, and "remote" corresponds to 
the receiving or destination network and device(s) which 
may also be on the left or right side of the gateway 240. 
"Originating" and "remote" are used in this description and 
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in the claims merely to distinguish one item from the other 
and do not necessarily represent any actual physical posi- 
tion. 

In order to generate the message 280, embodiments 
within the scope of the invention include means for gener- 
ating the message 280. One example of such a means is 
shown in FIG. 2 as the originating device 210. The origi- 
nating device 210 performs acts towards accomplishing the 
step of generating the message 280 as described herein. The 
originating device 210 may be any one of numerous devices 
that can output an electronic message in a specific format. As 
just one particular example, the originating device 210 may 
be a server having a version of Microsoft® Exchange Server 
loaded thereon. In the case of Microsoft® Exchange Server, 
the proximate device 210 may generate e-mail messages in 
the Multipurpose Internet Mail Extensions (MIME) format, 
calendar entries in the iCal format, contact entries in the 
vCard format and so forth. The type and number of formats 
in which the message 280 can be generated is limited only 
by the software and hardware capabilities of the originating 
device 210. 

The message 280 may be generated in a "push" fashion 
meaning the message 280 is generated in response to a 
predetermined event other than a request for the message 
280. For example, the originating device 210 might generate 
the message 280 at a predetermined time such as every hour 
on the hour. The message 280 might also be generated in 
response to an e-mail message arriving, or in response to any 
other stimulus recognized by the originating device 210. The 
message 280 may also be generated in a "pull" fashion in 
which the message 280 is generated in response to a specific 
request for information contained in the message 280. 

Regardless of whether the originating device 210 gener- 
ates the message 280 in response to a request or in response 
to any other stimulus, the originating device 210 generates 
a body 282 of the message 280 along with a means for 
addressing the destination device 270 or 271, one example 
of which is shown as address 281 in FIG. 2. All that is 
needed of address 281 is that it identifies the location of a 
remote destination device 270 or 271 either directly or 
indirectly by reference to another mechanism such as a 
look-up table. For example, the address 281 might be the 
specific uniform resource locator (URL) or phone number of 
the remote destination devices 270 or 271. Alternatively, the 
address 281 might be more generic such as "John Doe — 
Cellular Phone" in which the address 281 must be compared 
to a look-up table to obtain the specific address as described 
further below. 

The message 280 is transmitted to the gateway 240 so that 
the message 280 (or its associated address information) can 
be processed by the gateway 240 in preparation for routing 
the message 280 to a remote device 270 or 271. Accordingly, 
embodiments within the scope of the present invention 
include a means for transmitting the message 280 from the 
originating device 210 to the gateway 240. An example of 
such a means is shown in FIG. 2 as the originating network 
220. First, the originating network 220 receives the message 
280 from the originating device 210 using a protocol com- 
patible with the originating network 220. The originating 
network 220 may be any medium capable of transmitting the 
message 280 whether all wired, all wireless, or partially 
wireless. The originating network 220 may be a wide area 
network, a local area network, or a combination of both and 
use any protocol such as, for example, HyperText Transport 
Protocol (HTTP). In another example of the means for 
transmitting the message from the originating device 210 to 
the gateway 240, originating device 210 and the gateway 
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240 are both disposed within a common device such as a 
server. In this case, the originating network 220 is located 
internal to the server. 

Optionally, for scalability purposes, the means for trans- 

5 mining the message 280 to the gateway 240 may also 
include a sending queue 230. The sending queue 230 may 
receive messages from several originating networks and/or 
several originating devices so that the messages are avail- 
able at the gateway 240, and so that the messages may be 

to provided to several gateways as shown in FIG. 3. 

FIG. 3 shows that the environment 200 is scalable in that 
the number of originating networks and the number or 
gateways handling messages from these networks may be 
adjusted as needed. Specifically referring to FIG. 3, the 

15 sending queue 230 receives messages from a plurality of 
originating devices 210 and 211 over a plurality of origi- 
nating networks 220 and 221, respectively. Also FIG. 3 
shows that the sending queue 230 can feed messages to a 
plurality of gateways 240 and 241. Although only two 

20 originating networks, originating devices, and gateways are 
shown, it will be apparent from this description that the 
number of originating devices, originating networks, and 
gateways may be scaled up or down as appropriate. 
For example, if the gateway 240 is fast enough to process 

25 messages from many originating networks, there may be 
many originating networks inputting messages to the send- 
ing queue 230 and a fewer number of gateways dequeueing 
messages from the sending queue 230. On the other hand, if 
the gateway 240 is not fast enough to process messages from 
an originating network, there may be relatively few origi- 
nating networks providing messages to the proximate queue 
230, and a larger number of gateways (e.g., gateways 240 
and 241) dequeueing messages from the sending queue 230. 
The sending queue 230 may be any queue capable of 
receiving messages, storing messages, and holding those 
messages out for dequeueing by the gateway 240. For 
example, sending queue 230 might be a Microsoft® Mes- 
sage Queue (MSMQ) developed by Microsoft Corporation, 
The gateway 240 then dequeues the message 280 from the 

40 originating queue 230. 

After processing by the gateway 240 or 241, the message 
is fed into a remote queue 250 which is also provided for 
scalability purposes to allow the number of remote destina- 

45 tion devices services by the gateways to be scaled up or 
down as appropriate. The remote queue 250 will be 
described in more detail further below. 

The gateway performs several functions which will be 
described in greater detail to with respect to FIGS. 4, 5 and 

50 6. At a high functional level, the gateway 240 determines the 
address of the remote device 270 so that the message 280 
can be properly routed. Thus, embodiments within the scope 
of the present invention include means for determining a 
specific address of the destination device 270. 

55 In this description and in the claims, "specific address" 
means any address which comprises enough information to 
properly route the associated message over a remote net- 
work 260 or 261 to a remote device 270 or 271. Examples 
of a specific address include a phone number or uniform 

60 resource locator (URL). If the address 281 associated with 
the message 280 is specific, the means for determining a 
specific address of a destination device 270 or 271 may 
simply include reading the address 281 from the message 
280. 

65 "Generic address" means any address which requires the 
aid of a reference source to properly route the associated 
item to its destination. For example, "John Doe's home 
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phone number in Chicago" may be sufficient to properly Optionally, for scalability purposes at the remote side of 

route a message via a phone call only if a Chicago phone gateway 240, the means for transmitting the message 280 to 

book is referenced to obtain the specific phone number. If the remote device 280 may also include a remote queue 250. 

the address 281 is generic, the means for determining a The remote queue 250 may receive messages from several 

specific address of a destination device 270 or 271 may 5 gateways and may provide those messages to several remote 

perform specific acts such as reading the generic address, networks as shown in FIG. 3. Thus, if the gateway 240 is fast 

and looking up the specific address associated with the enough to process messages for many remote networks, 

generic address in a table or other information source. ^ere may be relatively few gateways inputting messages to 

A . , , , i_ r , j the remote queue 250 and a larger number of remote 

As described above, in order to be in a format recognized . #u 7 c *u , icn 

, * j • -iAn <vii it. r , n ,i ^ 1fl networks that receive messages from the remote queue 250. 

by a remote device 270 or 271, the format of the message 1U ~ t . , , f ~ AfX . , e . u . 

c , , j ' , j » . ... x On the other hand, if the gateway 240 is not fast enough to 

280 must often be changed. Thus, embodiments within the I . , ' . , t , , 

c . . * i j r • i . process messages for a single remote network, there may be 

scope of the invention include means for manipulating the , u r . • . .u 

r «n« » • r . -j. . a larger number of gateways inputting messages to the 

message 280 to be in a format recognized by any such f -,. n *? , \. , ,? . c 

& . . . ~ j * remote queue 250, and a relatively small number of remote 

remote destination device. Inese and other means are , , c : u t ^n, 

, ,; . " , j . . 4t nTO . A , networks drawmg messages from the remote queue 250. The 

descnbed m further detail with respect to FIG. 4. 15 --n u ui r • • 

F remote queue 250 may be any queue capable of receiving, 

In order to be properly transmitted to a remote device 270 sloringj and providin g the meS sage 280 to the remote 

or 271, the message 280 must be transmitted over a remote network 260. For example, proximate queue 250 might also 

network 260 using a protocol recognized by the particular be a Microsoft® Message Queue (MSMQ) developed by 

remote network 260 or 261. Accordingly, embodiments Microsoft Corporation. 

within the scope of the present invention include means for 20 ^ ^ message * 280 is transmitted over a remote 
transmitting the message 280 using a protocol compatible netW0fk 26Q 0f m {{ [s recdved by a destination device 
with the desired remote network 260 or 261 These and other 2?0 0f 2n Accordingly> embodiments within the scope of 
means are descnbed in detail with respect to FIG. 4. ^ presenl invention mchlde means for rece i vin g the mes- 
However, as an example of the functionality of gateway 2$ sage 2 80. This means is shown in FIG. 2 as a remote device 
240 described in reference to FIG. 3, suppose that originat- 270 or 271. The remote device 270 may be any wireless 
ing device 210 creates an e-mail message 280 in a MIME device such as a cellular phone with or without alphanu- 
format (a standard Internet e-mail format enabling mer j c text receiving capability, a text pager, a lap top 
attachments), and transmits the message 280 over the origi- computer, a hand held computer, or any other wireless 
nating network 220 to the gateway 240 using the standard 3Q device. The remote device 271 may be a "wired" device such 
Internet Hypertext Transport Protocol (HTTP). Suppose as a desk top computer, a conventional telephone, a corn- 
further that the remote network 260 uses a proprietary puter server, or any other wired device. In this description 
wireless protocol #1, and that the remote device 270 recog- and j n me c i amiS( a "wired" device includes any device that 
nizes data in a proprietary wireless format #2. In this case, ^ not wireless and that is capable of receiving an electronic 
the gateway 240 converts the message 280 from MIME 35 message. 

format to the proprietary format #2, and transmits the mG 4 is a m0fe detailed schematic diagram of the 

message 280 over the remote network 280 using the pro- gate way 240 and queues 230 and 250 of FIG. 2. An 

prietary protocol #1. originating message handler 404 dequeues the message 280 

Subsequently, the gateway 240 might convert another f rom the sending queue 230 and feeds the message 280 to a 

message destined for another remote device 271 over 40 message processor 406. Devices and modules for reading 

another remote network 261 even if the other remote device da t a from a queue and writing the message to another unit 

271 does not recognize proprietary data format #2, and even are well-known to those skilled in the art. The message 

if the other remote network 261 does not use proprietary processor 406 uses the locator module 408 to access infor- 

protocol#l. The gateway 240 dynamically adjusts as needed mation in the mass memory 410, uses the device driver 

to reformat the message 280 and provide the reformatted 45 interface 412 to interface with one of the device modules 

message 280 using the proper protocol as described herein. /v-F located in device driver library 414, uses an encryption 

After gateway 240 has manipulated the message 280 to be interface 416 to interface with one of the encryption mod- 

in a formal recognized by a remote device 270 or 271, the ules A-F located in the encryption module library 418, uses 

message 280 is transmitted. Accordingly, embodiments an authentication interface 420 to interface with an authen- 

within the scope of the present invention include means for 50 tication module 422, and uses a network driver interface 424 

transmitting the message 280 to a remote device 270 or 271. to interface with one of the network driver modules from the 

An example of this means is shown in FIG. 2 as a remote network driver library 426. Note that although interfaces 

network 260 or 261. 408, 412, 416, 420, 424 and 434 are shown as being boxes, 

The gateway 240 transmits the reformatted message 280 they really represent a standardized structure for calling 

using a protocol compatible with the particular remote 55 modules and retrieving information. These calling functions 

network described, such as 260 or 261. The remote networks may be performed using an Application Program Interface 

260 or 261 may be any network capable of transmitting the or API. 

message 280 to the remote devices 270 or 271 whether all The specific operation of an exemplary gateway 240 is 

wired, all wireless, or partially wireless. The originating now described. In order to route the message 280 to an 

network 220 may be a wide area network, a local area 60 appropriate destination device 270 or 271 (FIG. 2), the 

network, or a combination of both and may use any protocol specific address of the destination device is to be deter- 

such as, for example, HTTP, or proprietary wireless carrier mined. Accordingly, embodiments within the scope of the 

protocols. Since wireless carriers typically have their own present invention include a means for determining a specific 

proprietary protocols, and since there are many types of address of a destination device such as devices 270 or 271. 

wireless devices each recognizing their own data formats, 65 For example, if the address 283 associated with the message 

the flexible gateway 240 of the present invention is particu- 280 is a specific address, then the means for determining the 

larly useful in communicating with wireless devices. specific address includes an act of reading the address 281 
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by the message processor 406 and the corresponding hard- 280 already includes a specific identification of a remote 

ware and/or software that performs this act. device such as device 270, then the means may include 

Alternatively, if the address 281 associated with the executable code and/or hardware for performing the act of 

message is a generic address, the means for determining the Identifying the device driver associated with the specific 

specific address is more complex. For example, after reading 5 identification of the remote device 270 by simply reading the 

.l "ion * *u specific identification of the remote device 270 from the 

the message 280, the message processor 406 transmits the ^css e 280 

message 280, along with the address 281 to the locator me ssage . 

j I Ano - 4 j ■ - 1 AA a rp. Otherwise, if the address 281 associated with the message 

module 408 associated with the mass memory 410 The ^ ad sof 

mass memory uv may De aiqr su.tame device examples or vjdes • eciflc address 2gl 

to the locator module 408 to 

which include the magne tic hard disk dnve 27. he system " ]ook J of ^ remo(e ^ ^ jn ^ 

^ t t, m 7mr m*. / a tb6 , Km0V - mass memory 410 using a data structure representing an 

able optical disk 31 of FIG. 1. The tabk located on the mass identiflcation y lable . if the mess ^ ge processor 

memory 410 assocates the generic address with a specific m previously provided a generic address t0 me loca[or 

address. module 408, the specific address read from the address table 

FIG. 5 shows such an address table 500. The two left hand 500 (p IG ^ may be ^ t0 look up the spec ifi c type 0 f the 

columns 504, 506 list generic parameters of such as a user remote device 270. 

name in column 504 and a general device description in FIG. 6 shows an example of an identification table that 

column 506. For example, in row 502 of the address table ^ used {0 iook up the speciflc type of a remQte deyice 

500, the generic parameters are "John Doe" and "Cellular 270 Qf 2?1 ^ lefl hand column 604 Usts the specific 

Phone". The locator module 408 reads the specific address addfess of tfae TQmQ{e device For example> row 602 of 

associated with the generic address from the specific address cdumD m me specific addfess i.goo-5554212 iden- 

column 508 of the address table 500. For example, if the tified jn column 50g f0W 502 of me address table 500 u ^ 

generic address of the address 281 is John Doe's cellular be enl ih&{ taMcs m and 60Q can bc intcgrated int0 

phone, the specific address read from table 500 will be a Qne taMe tf desired The column 606 lists lhe specific type 

telephone number such as 1-800-555-1212. The locator of the remote device such as device 270 associated with the 

module 408 provides this specific address to the message specific addr£SS such ^ for example> «ABC Alphatext 

processor 406. There may be numerous rows of the address phonc 50(X)0 » the locat0f module m reads the 

table 500, each having an associated entry corresponding a spedfic typc of the rcmotc deyicc 270 from the idcntifier 

generic address to a specific address. 3o teblc 600 and providcs the resu i t to the message processor 

The remote devices 270 or 271 recognize data presented 495 The message processor 406 determines the name of the 

only in certain formats. If this format is different from the device module based on the identification of the remote 

format of the message 280 generated by the originating device 270 according to well known techniques such as 

device, the message 280 needs to be manipulated to be in the looking up the name of the device module in a table, 

format recognized by the remote device 270 or 271. 35 Alternatively, the device module name may be provided in 

Accordingly, embodiments within the scope of the present column 606 of the identifier table 600 instead of the iden- 

invention include means for manipulating the message 280 tification of the remote device 270. 

such that the message 280 is in a format recognized by a In order tQ deten nine the appropriate driver chain as 

remote device such as devices 270 or 271. An example of desC ribed above, it may be necessary to identify the network 

such a means is also described with reference to FIG. 4. 4Q driver module that can manipulate the message 280 to be in 

The means for manipulating the message 280 may include a format recognizable by the remote device 270. 
executable code and/or hardware for transporting the mes- Accordingly, embodiments within the scope of the present 
sage 280 from memory location to memory location invention include a means for identifying the network driver 
between each manipulation. However, in FIG. 4, a message module. The means for identifying the network driver mod- 
object 428 is used to represent the message 280 in all stages 45 u i e may be similar to the means for identifying the device 
of manipulation. The message object 428 may be, for module described above. For example, after the specific 
example, an abstract data type. Thus, one memory location address is determined, column 608 corresponding to row 
is allocated to the message 280 instead of a memory location 602 of the identification table may be referenced to deter- 
being allocated for each manipulation of the message 280. m ine the specific identification of the remote network, or the 

In order to further manipulate the message 280 now stored 50 specific identification of the remote network driver module, 

within the message object 428 in such a fashion, the gateway For example, the column 608 lists the specific type of the 

240 determines an appropriate chain of one or more modules remote network 260 on which the remote device 270 resides 

needed to properly manipulate and route the message 280. In such as, for example, "Wireless Network XYZ." Thus, the 

order to determine this chain, the device module that can locator module 308 reads the specific types from column 

manipulate the message 280 must be in a format recogniz- 55 604 and 606 of identifier table 600 and provides the specific 

able by the remote device 270 or 271. Accordingly, embodi- types to the message processor 406. The names "ABC 

ments within the scope of the present invention include Alphatext Phone 50000" and "Wireless Network XYZ" are 

means for identifying the device module. Note that by intended to be fictional and are not intended to represent any 

identifying the specific type of the remote device, one has real device or network. These names are provided for 

also identified the device since the identity of the device $ 0 illustrative purposes only. 

module has a well known association with the identity of a it should be noted that the determination of the appropri- 

device. For example, device manufacturers typically widely a te driver chain may be performed in one step at the same 

publish over the Internet the names of device drivers that can time as the device module is determined by looking up the 

operate with each of their products. specific address in the table 600 of FIG. 6. This allows the 

Referring to FIG. 4, examples of such a means for 65 appropriate device module, network driver module to be 

identifying the device module associated with a remote determined at the same time by accessing the table 600 just 

destination device 270 are now described. If the message once. 
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The identifier table 600 of FIG. 6 also includes a column The device module called by the message processor 406 

610 for registration data. Registration data may include and provided with the message 280 is the first module in the 

device specific information regardingThe re ceipTo fines- chain. The preference data obtained from the identifier table 

sages at a remote device 270 or 271. For example, the 600 of FIG. 6 may indicate that encryption is desired. If 

registration data might include what encryption technique 5 encryption is desired the preference data will also identify 

should be used, if any, in encrypting the message 280. This the encryption module within the encryption module library 

encryption technique would correspond to decryption soft- 418 that corresponds^ encryption software available on the 

ware present on the remote device 270. Other preferences « mole dev t lce 270 Thus, embodiments wnmn the scope of 

might include whether attachments in the message 280 are «•» P rese £ * n c ve °" l " lc ' u h de means for encry C/ 

to be ignored. For example, the remote device 270 may not 10 me ^<= Specifically, the message processor 406 calls 

t . , & * „ i_ . ■ the identified encryption module of the encryption module 

be able to represent an attachment. . J J. . . t c J \ , , 

r library 418 through the encryption interface. As described 

In this fashion, the message processor 406 may determine above for the deyice moduleSj all or of the encryption 

the identification of the device module associated with a modu i es may be permanently linked with the message 

remote device 270 or 271, the identification of the network proce ssor 406. The function of the authentication module 

driver module associated with a remote network 260 or 261, ^ 422 ^ be described fu nhtT below< 

the identification of any encryption modules that are to be ^ 24Q ^ othef Ubfaries of 

used, and an indication of other registration data associated moduJes ^ ^ ^ m ^ gQ processor 406 mterfaces wit h 

with the type of a remote device 270 or 271. an inlerface 434 For exampkj the gateway 24 0 may 

In order to use the chain of modules appropriate for a ^ mc i u d e a library of compression modules. The mode of 
remote device 270 or 271, a remote network 260 or 261, and compression corresponding to a particular type of remote 
the associated preferences, embodiments within the scope of device 270 or 271 may be identified in the registration data 
the present invention include means for accessing the device read i mm me i oca t 0 r module 410. The appropriate corn- 
module associated with the remote device 270. For example, pre ssion module corresponding to the compression software 
after determining the appropriate device module, the mes- on tne remo te device 270 may then be called and the 
sage processor 406 calls that device module from a device message 280 passed to the compression module for corn- 
module library 414 through a device driver interface 412. pression. 

The message 280 is then provided as the message object 428 Ultimately, after manipulation by the appropriate device 

to the appropriate device module through the device driver module> and poss ible manipulation by appropriate encryp- 

interface 412. The device module then manipulates the ^ tion and/of compress i on mo dules, and other modules as 

message 280 to be in a format recognized by the remote desired, the message 280 is in a format that a remote device 

device 270, and provides the reformatted message 280 back 2 70 or 271 can handle. The reformatted message is then 

through the device driver interface 412 to the message prov ided to a desired remote device such as devices 270 over 

processor 406 as the message object 428. ^ remote network 260. The remote network 260 may 

The device driver interface 412 may be, for example, a 35 include numerous devices which communicate with each 

COM interface and the device modules may be COM omer using a specific protocol. Therefore, the message 280 

modules. Software appli cations may be built using compo- ^ transmitted over the remote network 260 using a protocol 

nents. Each component is capable of performing one or more compatible with the remote network 260. Accordingly, 

functions in assisting the software application. COM is a embodiments within the scope of the present invention 

specification for building components and for creating appli- 4Q include means for transmitting the message 280 using a 

cations from these components. An advantage of using protocol compatible with the remote network 260. An 

COM components is that the components can be dynami- example of such a means is described with reference to FIG. 

cally linked to the application while the application is 4 

running by being called by the application. The COM -j^ ga t e way 240 first identifies the network driver asso- 

module and the application are linked through a COM 45 cialed witb a remot e device 270 or 271. The message 

interface. Thus, the appropriate device module may be processor 406 then accesses the appropriate network driver 

dynamically linked with the message processor 406 as the usmg a me ans for accessing an appropriate network driver 

message processor 406 is running. module for a remote device. For example, the message 

There are other structures and methods for accessing the processor 406 calls the network driver module from a 
appropriate device module. For example, all of the device 50 network driver library 426 through a network driver inter- 
modules in the entire device driver library 414 may be face 424. The message 280 is then provided through the 
permanently linked to the message processor 406 thus remote queue 250 to a remote network such as network 260 
eliminating the need to dynamically hnk the appropriate in the proper protocol. The network driver modules may be 
device module. Alternatively, more commonly accessed COM modules, and the network driver interface 424 may 
device drivers may be permanently linked to the message 55 also be COM interfaces. Ultimately, the message is received 
processor 406 while less commonly accessed device mod- at the remote device 270 and the message 280 can be 
ules may be dynamically linked through the COM interface. interpreted by the remote device 270 and by any user that is 

Each device module may be provided by a gateway associated with the remote device 270. 

device builder, or alternatively, may be provided by a remote Referring to FIG. 2, the originating device 210 is the 

device manufacturer. Device modules corresponding to a 60 origination device and the remote device 270 is the desti- 

particular device are typically available from the manufac- nation device when the message 280 is transmitted from the 

turers of that device. For example, such device modules may proximate device 210 to the remote device 270. However, 

be downloaded from a World Wide Web site hosted by the messages may also be transmitted from a remote device 270 

manufacturer. The design of a device driver interface 412 is or 271 to the originating device 210. In this case, device 270 

arbitrary. All that is required is that the device module 4 1 4 65 or 271 is the originating device and device 210 is the 

export an interface that complies with the device driver destination device. Such messages may include a request for 

interface 412 supported by the current invention. the data such as e-mail messages, contact entries, or calendar 
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entries. In addition, the destination device 210 may be a 
remote server residing anywhere on the Internet such as an 
Instant Messaging Server or a Web server. The message 280 
could include an instant message in the case of an Instant 
Messaging Server, or a Web page in the case of a Web server. 5 
However, the message 280 may include any other message 
types. 

In order to transmit a message from an originating device 
270 or 271 to a remote destination device 210, the originat- 
ing device 270 or 271 first generates a message in a 10 
particular format. The device 270 or 271 then transmits that 
message over the network 260 or 261 to the remote queue 
250 using a specific protocol. The gateway 240 then 
dequeues the message from the queue 250 and provides the 
message to the message object 428 of the message processor 15 
406. 

The message may include a specific address of the device 
270 or 271 along with an identification of the device 270 or 
271. The message 280 is provided to the locator module 408 
which determines the proper device module, the proper 20 
encryption module, and any other modules associated with 
the originating device 270. The message processor 406 then 
constructs a chain of modules by calling the appropriate 
device module, and any other modules as appropriate. 

Proper security may be obtained by transmitting the 
message from the device 270 or 271 using encryption 
software. Optionally, some level of security may be obtained 
by an authentication module 422 which is accessible to the 
message processor 428 through the authentication interface 3Q 
420. The authentication module may check for a password 
which gives the device 270 or 271 permission to access the 
information requested in the message 280. 

In the event that access is granted, the manipulated 
message is then transmitted by a connector 430 (e.g., an 35 
HTTP connector) to the proximate queue 230 using the 
protocol appropriate for the network 220 such as HTTP. The 
message is then transmitted over the network 220 to the 
destination device 210 where the message may be pro- 
cessed. 40 

As described above, the message processor 406 refer- 
ences the locator module 408 for address data about the 
proximate 210, and for preference and module data about the 
device 270 or 271. Thus, the message processor 406 does not 
need to refer to the locator module 408 to determine this 45 
information when processing the response to this inbound 
message assuming that the message processor 280 retains 
the data from the locator module 410 until after the response 
is processed, and assuming that the message processor 408 
recognizes the response is a response to the message. 50 

In summary, a flexible gateway is provided which enables 
communication over a broad range of networks between a 
broad range of devices. The present invention may be 
embodied in other specific forms without departing from its 
spirit or essential characteristics. The described embodi- 55 
ments are to be considered in all respects only as illustrative 
and not restrictive. The scope of the invention is, therefore, 
indicated by the appended claims rather than by the fore- 
going description. All changes which come within the mean- 
ing and range of equivalency of the claims are to be 60 
embraced within their scope. 

What is claimed and desired to be secured by United 
States Letters Patent is: 

1. In a networked computer system that includes one or 
more originating devices for originating data or messages, 65 
and wherein the originating devices are logically connected 
to and communicate using one or more originating protocols 
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with one or more originating networks logically connected 
to a gateway, the gateway in turn being logically connected 
to one or more remote networks that are logically connected 
to and that communicate to one or more remote destination 
devices using one or more receiving protocols, at least some 
of which are different from the originating protocols, a 
method of forwarding the originating data or messages from 
the one or more originating devices through the gateway to 
the one or more remote destination devices notwithstanding 
the differences used in the originating and receiving 
protocols, the method comprising the following: 

a step for generating, at one or more of the originating 
devices, data or a message intended for at least one 
remote destination device; 
a step for communicating the generated data or message 
through one or more originating networks to a gateway 
using the one or more of the originating protocols; 
a step for identifying at the gateway a device type, a 
network type, or both, for the at least one remote 
destination device; 
a step for identifying, from a plurality of device modules 
at the gateway for manipulating data and messages into 
any of a plurality of formats or protocols for diverse 
device and network types, a device module associated 
with the device type, network type, or both, identified 
for the intended remote destination device; and 
a step for using the identified device module to manipu- 
late the data or message so that the data or message is 
then transmitted from the gateway through the one or 
more remote networks to the intended remote destina- 
tion device using a protocol and a format recognized by 
the intended remote destination device, irrespective of 
differences in the originating and receiving protocols. 

2. The method of claim 1, wherein the step for commu- 
nicating comprises the following: 

an act of communicating the generated data or message 
through one or more originating networks to the gate- 
way using Hypertext Transfer Protocol (HTTP). 

3. The method of claim 1, further comprising the follow- 
ing: 

a step for transmitting the data or message over the one or 
more remote networks to the intended remote destina- 
tion device using the protocol and the format recog- 
nized by the intended remote destination device. 

4. The method of claim 3, wherein the step for transmit- 
ting comprises the following: 

an act of transmitting the data or message over a wireless 
network to the intended remote destination device. 

5. The method of claim 3, wherein the step for transmit- 
ting comprises the following: 

an act of transmitting the data or message over a remote 
network that is at least partially wireless. 

6. In a networked computer system that includes one or 
more originating devices for originating data or messages, 
and wherein the originating devices are logically connected 
to and communicate using one or more originating protocols 
with one or more originating networks logically connected 
to a gateway, the gateway in turn being logically connected 
to one or more remote networks that are logically connected 
to and that communicate to one or more remote destination 
devices using one or more receiving protocols, at least some 
or which are different from the originating protocols, a 
computer program product for implementing a method of 
forwarding the originated data or messages from the one or 
more originating devices through the gateway to the one or 
more remote destination devices notwithstanding the differ- 
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ence used in the originating and receiving protocols, the 
computer program product comprising: 

a computer readable medium for providing computer 

program code means utilized to implement said 

method; and 5 
wherein said computer program code means is comprised 

of executable code for implementing the following: 

a step for generating, at one or more of the originating 
devices, data or a message intended for at least one 
remote destination device; 10 

a step for communicating the generated data or mes- 
sage through one or more originating networks to a 
gateway using one or more originating protocols; 

a step for identifying at the gateway a device type, a 
network type, or both, for the at least one remote 15 
destination device; 

a step for identifying, from a plurality of device mod- 
ules at the gateway for manipulating data and mes- 
sages into any of a plurality of formats or protocols 
for diverse device and network types, a device mod- 20 
ule associated with the device type, network type, or 
both, identified for the intended remote destination 
device; and 

a step for using the identified device module to manipu- 
late the data or message so that the data or message 25 
is then transmitted from the gateway through the one 
or more remote networks to the intended remote 
destination device using a protocol and a format 
recognized by the intended remote destination 
device, irrespective of differences in the originating 30 
and receiving protocols. 

7. The computer program product of claim 6, wherein the 
executable code for implementing the step for communicat- 
ing comprises executable code for implementing the follow- 
ing: 

an act of communicating the generated data or message 
through one or more originating networks to the gate- 
way using HyperText Transfer Protocol (HTTP). 

8. The computer program product of claim 6, further 
comprising executable code for implementing the following: 

a step for transmitting the data or message over the one or 
more remote networks to the intended remote destina- 
tion device using the protocol and the format recog- 
nized by the intended remote destination device. 45 

9. The computer program product of claim 8, wherein the 
executable code for implementing the step for transmitting 
comprises executable code for implementing the following: 

an act of transmitting the data or message over a wireless 
network to the intended remote destination device. 50 

10. The computer program product of claim 9, wherein 
the executable code for implementing the step for transmit- 
ting comprises executable code for implementing the fol- 
lowing: 

an act of transmitting the data or message over a remote 55 

network that is at least partially wireless. 
U. A networked computer system for permitting data or 
messages that are originated using one or more originating 
protocols to be communicated across one or more networks 
to a remote destination that uses a receiving protocol dif- 60 
ferent from the originating protocols, comprising: 
one or more originating devices for originating data or 

messages using one or more originating protocols; 
one or more originating networks logically connected to 
the one or more originating devices and which com- 65 
municate therewith using the one or more originating 
protocols; 



35 



40 



gateway means logically connected to the one or more 
originating devices through the one or more originating 
networks, for receiving the originated data or messages 
using the one or more originating protocols, said gate- 
way means comprising: 

means for determining a specific address for each 
received data or message so that a destination device 
or network type may be identified for the received 
data or message; 

means for identifying from a plurality of device mod- 
ules at the gateway for manipulating received data 
and messages into any of a plurality of formats or 
protocols for diverse device and network types, a 
device module associated with each received data or 
message's destination device type, network type, or 
both; and 

means for manipulating each received data or message 
so that each received data or message is then trans- 
mitted from the gateway through one or more remote 
networks to an intended remote destination device 
using a protocol and a format recognized by the 
intended remote destination device, irrespective of 
differences in the originating and receiving proto- 
cols; 

one or more remote networks logically connected to the 
gateway; and 

at least one or more remote destination devices logically 
connected through the one or more remote networks. 

12. The networked computer system of claim 11, wherein 
at least one of the one or more remote networks are wireless. 

13. The networked computer system of claim 11, wherein 
all of the one or more remote networks are wireless. 

14. The networked computer system of claim 11, wherein 
the at least one or more remote destination devices comprise 
a cellular phone. 

15. In a networked computer system that includes one or 
more originating devices for originating data or messages, 
and wherein the originating devices are logically connected 
to and communicate using one or more originating protocols 
with one or more originating networks logically connected 
to a gateway, the gateway in turn being logically connected 
to one or more remote networks that are logically connected 
to and that communicate to one or more remote destination 
devices using one or more receiving protocols, at least some 
of which are different from the originating protocols, a 
computer program product for implementing on the gateway 
a method of forwarding the originating data or messages 
from the one or more originating devices through the 
gateway to the one or more remote destination devices 
notwithstanding the differences used in the originating and 
receiving protocols, the computer program product compris- 
ing: 

a computer readable medium for providing computer 
program code means utilized by said gateway to imple- 
ment said method; and 
wherein said computer program code means is comprised 
of executable code for implementing the following: 
a step for receiving at the gateway data or a message 

generated at one or more of the originating devices, 

the received data or a message intended for at least 

one remote destination device; 
a step for identifying at the gateway a device module 

associated with the intended remote destination 

device, comprising: 

an act of reading an address of the intended remote 
destination device from the data or message; 

an act of looking up the address in a locator table 
associating the address with a specific device type, 
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the specific device type corresponding to the 
device module associated with the destination 
device; and 

an act of reading the specific device type from the 
locator table; and 5 
a step for using the identified device module to manipu- 
late the received data or message so that the data or 
message is then transmitted from the gateway 
through the one or more remote networks to the 
intended remote destination device using a protocol 10 
and a format recognized by the intended remote 
destination device, irrespective of differences in the 
originating and receiving protocols. 

16. The computer program product of claim 15, wherein 
the executable instructions for performing the step for using 15 
the identified device module to manipulate the received data 

or message comprises computer executable instructions for 
performing the following: 

an act of calling the device module from a library of 

device modules; and 20 
an act of interfacing with the device module through an 
interface. 

17. The computer program product of claim 15, wherein 
the executable instructions for performing the step for using 
the identified device module to manipulate the received data 25 
or message comprises executable instructions for perform- 
ing the following: 

an act of calling a component object model compliant 
(COM) device module corresponding to the specific 3Q 
device type from a library of COM device modules; 
and 

an act of interfacing with the COM device module 
through a COM interface. 

18. The computer program product of claim 15, wherein 35 
the executable instructions for performing the step for 
receiving at the gateway data or a message generated at one 

or more of the originating devices comprises executable 
instructions for performing the following: 

an act of receiving the data or message at a sending queue 40 
associated with the gateway. 

19. The computer program product of claim 18, wherein 
tho executable instructions for performing the step for 
receiving at the gateway data or a message generated at one 

or more of the originating devices comprises executable 45 
instructions for performing the following: 

an act of the gateway dequeueing the data or message 
from the sending queue. 

20. The computer program product of claim 19, wherein 
the executable instructions for performing the act of receiv- so 
ing the data or message at a sending queue further compris- 
ing executable instructions for performing the following: 

an act of the sending queue delivering data or messages to 
a plurality of gateways including the gateway. 

21. In a networked computer system that includes one or 55 
more originating devices for originating data or messages, 
and wherein the originating devices are logically connected 

to and communicate using one or more originating protocols 
with one or more originating networks logically connected 
to a gateway, the gateway in turn being logically connected 60 
to one or more remote networks that are logically connected 
to and that communicate to one or more remote destination 
devices using one or more receiving protocols, at least some 
of which are different from the originating protocols, a 
computer program product for implementing on the gateway 65 
a method of forwarding the originating data or messages 
form the one or more originating devices through the 
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gateway to the one or more remote destination devices 
notwithstanding the differences used in the originating and 
receiving protocols, the computer program product compris- 
ing: 

a computer readable medium for providing computer 
program code means utilized by said gateway to imple- 
ment said method; and 
wherein said computer program code means is comprised 
of executable code for implementing the following: 
a step for receiving at the gateway data or a message 

generated at one or more of the originating devices, 

the received data or a message intended for at least 

one remote destination device; 
a step for identifying at the gateway a device module 

associated with the intended remote destination 

device, comprising: 

an act of reading an address of the intended remote 

destination device from the data or message; 
an act of looking up the address in a locator table 
associating the address with a specific network 
type, the specific network type corresponding to 
the network driver module associated with the 
remote network; and 
an act of reading the specific network type from the 
locator table, and wherein the executable instruc- 
tion for performing the step for identifying a 
device module associated with the intended 
remote destination device comprise executable 
instruction for performing the following: 
an act of looking up the address in the locator 
table, the locating table also associating the 
address with a specific device type, the specific 
device type corresponding to the device mod- 
ule associated with the intended remote desti- 
nation device; and 
an act of reading the specific device type from the 
locator table; 

a step for using the identified device module to manipu- 
late the received data or message so that the data or 
message is then transmitted from the gateway through 
the one or more remote networks to the intended 
remote destination device using a protocol and a format 
recognized by the intended remote destination device, 
irrespective of differences in the originating and receiv- 
ing protocols; and 
a step for transmitting the data or message to the intended 
remote destination device, comprising: 
a step for transmitting the message to the intended 
remote destination device over a remote network on 
which the destination device resides, comprising: 
a step for identifying a network driver module asso- 
ciated with the remote network; and 
a step for providing the message to the remote 
network using a protocol compatible with the 
remote network. 

22. The computer program product of claim 21, wherein 
the device module and the network driver module each 
comprises a COM module. 

23. The computer program product of claim 21, wherein 
the executable instructions for performing the step for 
transmitting the message to the intended remote destination 
device further comprises executable instructions for per- 
forming the following: 

an act of transmitting the message to a message queue. 

24. In a networked computer system that includes one or 
more originating devices for originating data or messages, 
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and wherein the originating devices are logically connected 
to and communicate using one or more originating protocols 
with one or more originating networks logically connected 
to a gateway, the gateway in turn being logically connected 
to one or more remote networks that are logically connected 5 
to and that communicate to one or more remote destination 
devices using one or more receiving protocols, at least some 
of which are different from the originating protocols, a 
computer program product for implementing on the gateway 
a method of forwarding the originating data or messages 10 
from the one or more originating devices through the 
gateway to the one or more remote destination devices 
notwithstanding the differences used in the originating and 
receiving protocols, the computer program product compris- 
ing: 15 
a computer readable medium for providing computer 
program code means utilized by said gateway to imple- 
ment said method; and 
wherein said computer program code means is comprised 
of executable code for implementing the following: 20 
an act of the gateway receiving data or a message 
generated at one or more of the originating devices, 
the received data or a message intended for at least 
one remote destination device; 
an act of the gateway reading, from the data or 
message, an address that either directly or indirectly 
identifies a location of the intended remote destina- 
tion device; 

an act of the gateway determining a device type, a 
network type, or both, associated with the address of 30 
the intended remote destination device; 

an act of the gateway identifying a device module that 
corresponds to the device type, network type, or both 
associated with the address of the intended remote 
destination device; 

an act of the gateway using the identified device 
module to manipulate the received data or message; 
and 

an act of the gateway transmitting the data or message 
from the gateway through the one or more remote 
networks to the intended remote destination device 
using a protocol and a format recognized by the 
intended remote destination device, irrespective of 
differences in the originating and receiving proto- 
cols. 

25. The computer program product of claim 24, further 
comprising executable code for implementing the following: 
an act of the gateway transmitting the data or message 
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over the one or more remote networks to the intended 



50 



remote destination device using the protocol and the 
format recognized by the intended remote destination 
device. 

26. The computer program product of claim 25, wherein 
the executable code for implementing the act of the gateway 55 
transmitting comprises executable code for implementing 
the following: 

an act of the gateway transmitting the data or message 
over a wireless network to the intended remote desti- 
nation device. 60 

27. The computer program product of claim 26, wherein 
the executable code for implementing the step for transmit- 
ting comprises executable code for implementing the fol- 
lowing: 



an act of the gateway transmitting the data or message 
over a remote network that is at least partially wireless. 

28. In a networked computer system that includes one or 
more originating devices for originating data or messages, 
and wherein the originating devices are logically connected 
to and communicate using one or more originating protocols 
with one or more originating networks logically connected 
to a gateway, the gateway in turn being logically connected 
to one or more remote networks that are logically connected 
to and that communicate to one or more remote destination 
devices using one or more receiving protocols, at least some 
of which are different from the originating protocols, a 
method of forwarding the originating data or messages from 
the one or more originating devices through the gateway to 
the one or more remote destination devices notwithstanding 
the differences used in the originating and receiving 
protocols, the method comprising the following: 

an act of the gateway receiving data or a message gen- 
erated at one or more of the originating devices, the 
received data or a message intended for at least one 
remote destination device; 

an act of the gateway reading, from the data or message, 
an address that either directly or indirectly identifies a 
location of the intended remote destination device; 

an act of the gateway determining a device type, a 
network type, or both, associated with the address of 
the intended remote destination device; 

an act of the gateway identifying a device module that 
corresponds to the device type, network type, or both 
associated with the address of the intended remote 
destination device; 

an act of the gateway using the identified device module 
to manipulate the received data or message; and 

an act of the gateway transmitting the data or message 
from the gateway through the one or more remote 
networks to the intended remote destination device 
using a protocol and a format recognized by the 
intended remote destination device, irrespective of dif- 
ferences in the originating and receiving protocols. 

29. The method of claim 28, wherein the act of the 
gateway using the identified device module comprises the 
following: 

an act of calling a COM device module corresponding to 
the intended remote destination device from a library of 
COM device modules; and 

an act of interfacing with the device module through a 
COM device driver interface. 

30. The method of claim 28, further comprising the 
following: 

a specific act of the gateway identifying other modules 
associated with the intended remote destination device; 
and 

a specific act of the gateway using the other modules to 
manipulate the received data or message. 

31. The method of claim 30, wherein the other modules 
include an encryption module. 

32. The method of claim 30, wherein the other modules 
include a compression module. 
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